1. Field of the Invention
The present invention relates to a system specifically designed to allow third-party smart cards to be recognized by computing devices configured to receive smart cards.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
2. Background Art
In modern computing it is desirable for a user to be interacting with a computing device, to stop interacting with the device, to move to a new location, and to begin interacting with a new device at precisely the point where the user stopped interacting with the first device. To perform such an activity a “smart card” may be used. A smart card is a card-like device that is physically inserted into the device and read by the device. The smart card provides information to the new device, for instance, that enables it to locate the data and computer programs necessary to re-create the user's interaction that was terminated on the old device.
To enable a computing device to understand the information a smart card is providing, a system must be used whereby the computing device is instructed how to interact with the smart card. Current systems that enable the use of smart cards, however, are inadequate because typically the system only applies to a single type of smart card that is to be used on a single type of device. There is no mechanism whereby a third-party smart card may be configured to operate with any given device. Before further discussing the drawbacks of current schemes, it is instructive to discuss how the nature of computing is changing.
The Nature of Computing
The nature of computing is changing. Until recently, modern computing was mostly “machine-centric”, where a user accessed a dedicated computer at a single location. The dedicated computer had all the data and computer programs necessary for the user to operate the computer, and ideally, it had large amounts of hardware, such as disk drives, memory, processors, and the like. With the advent of computer networks, however, different computers have become more desirable and the focus of computing has become “service-oriented”. In particular, computer networks allow a user to access data and computer programs that exist elsewhere in the network. When the user accesses such data or computer programs, the remote computer is said to be providing a service to the user. With the improvement in services available to users, the need to have a dedicated computer following the machine-centric paradigm is greatly reduced. The machine-centric paradigm also becomes much less practical in this environment because distributing services is much more cost-effective.
In particular, computers in a service-oriented environment have little need for powerful hardware. For instance, the remote computer processes the instructions before providing the service, so a powerful processor is not needed locally. Similarly, since the service is providing the data, there is little need to have large capacity disk drives locally (or on the local access hardware). In such an environment, one advantage is that computer systems have been implemented that allow a user access any computer in the system and still use the computer in the same manner (i.e., have access to the same data and computer programs).
For instance, a user may be in location A and running a word processor, a web browser, and an interactive multimedia simulation. In a service-oriented environment, the user might stop using the computer in location A and move to location B where the user could resume these computer programs on a different machine at the exact point where the user stopped using the machine at location A, as long as both computers had access via the computer network to the serves where the programs were being executed. An architecture that makes such an interaction possible is described below.
Multi-Tier Application Architecture
In the multi-tier application architecture, a client communicates requests to a server for data, software and services, for example, and the server responds to the requests. The server's response may entail communication with a database management system for the storage and retrieval of data.
The multi-tier architecture includes at least a database tier that includes a database server, an application tier that includes an application server and application logic (i.e., software application programs, functions, etc.), and a client tier. The application server responds to application requests received from the client. The application server forwards data requests to the database server.
FIG. 1 provides an overview of a multi-tier architecture. Client tier 100 typically consists of a computer system that provides a graphic user interface (GUI) generated by a client 110, such as a browser or other user interface application. Conventional browsers include Internet Explorer and Netscape Navigator, among others. Client 110 generates a display from, for example, a specification of GUI elements (e.g., a file containing input, form, and text elements defined using the Hypertext Markup Language (HTML)) and/or from an applet (i.e., a program such as a program written using the Java™ programming language, or other platform independent programming language, that runs when it is loaded by the browser).
Further application functionality is provided by application logic managed by application server 120 in application tier 130. The apportionment of application functionality between client tier 100 and application tier 130 is dependent upon whether a “thin client” or “thick client” topology is desired. In a thin client topology, the client tier (i.e., the end user's computer) is used primarily to display output and obtain input, while the computing takes place in other tiers. A thick client topology, on the other hand, uses a more conventional general purpose computer having processing, memory, and data storage abilities. Database tier 140 contains the data that is accessed by the application logic in application tier 130. Database server 150 manages the data, its structure and the operations that can be performed on the data and/or its structure.
Application server 120 can include applications such as a corporation's scheduling, accounting, personnel and payroll applications, for example. Application server 120 manages requests for the applications that are stored therein. Application server 120 can also manage the storage and dissemination of production versions of application logic. Database server 150 manages the database(s) that manage data for applications. Database server 150 responds to requests to access the scheduling, accounting, personnel and payroll applications' data, for example.
Connection 160 is used to transmit data between client tier 100 and application tier 130, and may also be used to transfer the application logic to client tier 100. The client tier can communicate with the application tier via, for example, a Remote Method Invocator (RMI) application programming interface (API) available from Sun Microsystems™. The RMI API provides the ability to invoke methods, or software modules, that reside on another computer system. Parameters are packaged and unpackaged for transmittal to and from the client tier. Connection 170 between application server 120 and database server 150 represents the transmission of requests for data and the responses to such requests from applications that reside in application server 120.
Elements of the client tier, application tier and database tier (e.g., client 110, application server 120 and database server 150) may execute within a single computer. However, in a typical t system, elements of the client tier, application tier and database tier may execute within separate computers interconnected over a network such as a LAN (local area network) or WAN (wide area network).
Smart Cards
In a multi-tier computer architecture computing sessions may be moved between computers in the network. One way to move between computers and to resume the user's computing session is to use a smart card. Typically each type of computing system uses only one type of smart card. There is no way for a third-party to take a generic smart card and configure it to be able to interact with a specific computing system because there is currently no system with which a developer may create instructions to perform such an action.